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[57] ABSTRACT 

A hardware authentication mechanism ensures that a device 
receiving a packet of copy-protected data has been autho- 
rized by the transmitting device to receive the packet of data. 
The transmitting device authenticates a receiving device and 
verifies that the receiving device is authorized to receive the 
copy-protected data. Once authenticated, the transmitting 
device then sends a write authentication transaction, includ- 
ing a physical identifier value representing the transmitting 
device, to the receiving device. This authentication transac- 
tion is preferably addressed to a predefined address in the 
receiving device. This address is preferably communicated 
from the receiving device to the source device during the 
earlier authentication process. Alternatively, the address is 
assigned by convention. In an alternative embodiment, the 
authentication transaction also contains additional 
information, such as one or more encryption keys which are 
needed by the receiving device to decipher and use the 
copy-protected data. Upon receiving the authentication 
transaction, the receiving device then latches the physical 
identifier value into a dedicated register. When a data packet 
is then received at the receiving device, the interface hard- 
ware of the receiving device compares the physical identifier 
value in the received data packet to the value stored in the 
dedicated register. If the physical identifier value in the 
received data packet and the value stored in the dedicated 
register are the same, the interface hardware receives the 
data packet. If the physical identifier value in the received 
data packet and the value stored in the dedicated register are 
not the same, the interface hardware does not receive the 
data packet. 

18 Claims, 3 Drawing Sheets 
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HARDWARE AUTHENTICATION 
MECHANISM FOR TRANSMISSION OF 
DATA BETWEEN DEVICES ON AN IEEE 
1394-1995 SERIAL BUS NETWORK 

FIELD OF THE INVENTION 

The present invention relates to the field of securely 
transmitting data over a data bus. More particularly, the 
present invention relates to the field of securely transmitting 
data over an IEEE 1394-1995 serial bus by authenticating 
the devices involved in the transmission. 

BACKGROUND OF THE INVENTION 

The IEEE standard, "IEEE 1394 Standard For A High 
Performance Serial Bus," ratified in 1995, is an international 
standard for implementing an inexpensive high-speed serial 
bus architecture which supports both asynchronous and 
isochronous format data transfers. Isochronous data trans- 
fers are real-time transfers which take place such that the 
time intervals between significant instances have the same 
duration at both the transmitting and receiving applications. 
Each packet of data transferred isochronously is transferred 
in its own time period. The IEEE 1394-1995 standard bus 
architecture provides multiple channels for isochronous data 
transfer between applications. A six bit channel number is 
broadcast with the data to ensure reception by the appropri- 
ate application. This allows multiple applications to simul- 
taneously transmit isochronous data across the bus structure. 
Asynchronous transfers are traditional data transfer opera- 
tions which take place as soon as possible and transfer an 
amount of data from a source to a destination. 

The IEEE 1394-1995 standard provides a high-speed 
serial bus for interconnecting digital devices thereby pro- 
viding a universal I/O connection. The IEEE 1394-1995 
standard defines a digital interface for the applications 
thereby ehrninating the need for an application to convert 
digital data to analog data before it is transmitted across the 
bus. Correspondingly, a receiving application will receive 
digital data from the bus, not analog data, and will therefore 
not be required to convert analog data to digital data. The 
cable required by the IEEE 1394-1995 standard is very thin 
in size compared to other bulkier cables used to connect such 
devices. Devices can be added and removed from an IEEE 
1394—1995 bus while the bus is active. If a device is so 
added or removed the bus will then automatically reconfig- 
ure itself for transmitting data between the then existing 
nodes. A node is considered a logical entity with a unique 
address on the bus structure. Each node provides an iden- 
tification ROM, a standardized set of control registers and its 
own address space. 

The IEEE 1394-1995 standard defines a protocol as 
illustrated in FIG. 1. This protocol includes a serial bus 
management block 10 coupled to a transaction layer 12, a 
link layer 14 and a physical layer 16. The physical layer 16 
provides the electrical and mechanical connection between 
a device or application and the IEEE 1394-1995 cable. The 
physical layer 16 also provides arbitration to ensure that all 
devices coupled to the IEEE 1394-1995 bus have access to 
the bus as well as actual data transmission and reception. 
The link layer 14 provides data packet delivery service for 
both asynchronous and isochronous data packet transport. 
This supports both asynchronous data transport, using an 
acknowledgement protocol, and isochronous data transport, 
providing real-time guaranteed bandwidth protocol for just- 
in- time data delivery. The transaction layer 12 supports the 
commands necessary to complete asynchronous data 
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transfers, including read, write and lock. The serial bus 
management block 10 contains an isochronous resource 
manager for managing isochronous data transfers. The serial 
bus management block 10 also provides overall configura- 

S tion control of the serial bus in the form of optimizing 
arbitration timing, guarantee of adequate electrical power 
for all devices on the bus, assignment of the cycle master, 
assignment of isochronous channel and bandwidth resources 
and basic notification of errors. 

10 Providers of content which is transmitted between devices 
over networks such as an IEEE 1394-1995 serial bus 
network are continually concerned about unauthorized 
copying of their programs by unscrupulous persons. For 
example, in a network such as an IEEE 1394-1995 serial bus 
network, when content is transmitted from a playing device, 
such as a digital video disk, to a display device, such as a 
television, this content stream can also be snooped and 
recorded by an unauthorized recording device, such as a 
video cassette recorder. The digital transmission of copy 
protected information between consumer electronics devices 

20 

and personal computers has led to additional concern among 
content providers, due to the new ability to make lossless 
copies of original source material. The personal computers 
provide a particular challenge due to the ability of users to 
load software to circumvent copy protection mechanisms. 
What is needed is a method and apparatus which is used to 
prevent such unauthorized copying or duplication. What is 
further needed is such a copy prevention system which 
cannot be circumvented by software running within a com- 
3Q puter system. 

SUMMARY OF THE INVENTION 

A hardware authentication mechanism ensures that a 
device receiving a packet of copy-protected data has been 
authorized by the transmitting device to receive the packet 

35 of data. The transmitting device authenticates a receiving 
device and verifies that the receiving device is authorized to 
receive the copy-protected data. Once authenticated, the 
transmitting device then sends an IEEE 1394 write 
transaction, including a physical identifier value represent - 

40 ing the transmitting device, to the receiving device. For 
purposes of discussion, this write transaction is herein 
referred to as an authentication transaction. This authenti- 
cation transaction is preferably addressed to a predefined 
address in the receiving device. This address is preferably 

45 communicated from the receiving device to the source 
device during the earlier authentication process. 
Alternatively, the address is assigned by convention. In an 
alternative embodiment, the authentication transaction also 
contains additional information, such as one or more encryp- 

50 tion keys which are needed by the receiving device to 
decipher and use the copy-protected data. Upon receiving 
the authentication transaction, the receiving device then 
latches the source physical identifier value into a dedicated 
register. When a data packet is then received at the receiving 

55 device, the interface hardware of the receiving device com- 
pares the physical identifier value in the received data packet 
to the value stored in the dedicated register. If the physical 
identifier value in the received data packet and the value 
stored in the dedicated register are the same, the interface 

60 hardware receives the data packet. If the physical identifier 
value in the received data packet and the value stored in the 
dedicated register are not the same, the interface hardware 
does not receive the data packet. 

65 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a protocol defined by the IEEE 
1394-1995 standard. 



03/26/2004, EAST Version: 1.4.1 



5,9< 

3 

FIG. 2 illustrates a format of an isochronous data packet 
of the IEEE 1394-1995 standard. 

FIG. 3 illustrates a block diagram of an IEEE 1394-1995 
serial bus network including a plurality of devices. 

DETAILED DESCRIPTION OF THE PRESENT 
INVENTION 

A hardware authentication mechanism ensures that a 
device receiving a packet of copy-protected data has been 
authorized by the transmitting device to receive the packet 
of data. After the transmitting device authenticates the 
receiving device and determines that the receiving device is 
an authorized listening device, the transmitting device then 
transmits a write transaction to a dedicated register in the 
receiving device. When this write transaction is received by 
the receiving device, the hardware interface circuit within 
the receiving device latches the source identifying value 
from the header of this write transaction into the dedicated 
register. Thereafter, when receiving copy-protected data, the 
source identifying value from the header of the data packets 
is compared to the value stored in the dedicated register If 
the values are the same, the interface circuit will then accept 
the data packet and allow the receiving device to process the 
data appropriately. If the values are not the same, the 
interface will prevent the receiving device from receiving 
the data packet. 

The authentication write transaction is preferably 
addressed to a predefined address in the receiving device. 
This predefined address is preferably communicated from 
the receiving device to the source device during the earlier 
authentication process. Alternatively, the address is assigned 
by convention. In an alternative embodiment, the authenti- 
cation transaction also contains additional information, such 
as one or more encryption keys which are needed by the 
receiving device to decipher and use the copy-protected 
data. 

Once a computer system or any other appropriate receiv- 
ing device includes the authentication system of the present 
invention implemented in hardware, software cannot be 
used to circumvent this authentication system. In this 
manner, a device cannot authenticate itself as a valid 
receiver of protected data using software. To be authenti- 
cated using the hardware system of the present invention, a 
receiving device must receive the authentication write trans- 
action and latch the source identifying value from the header 
of that transaction. Accordingly, if a device including the 
authentication mechanism of the present invention is pro- 
vided to a user, the user cannot then manipulate the device 
to receive streams of data for which the device is not 
authorized. 

A format of an isochronous data packet for transmission 
over an IEEE 1394-1995 serial bus network is illustrated in 
FIG. 2. The format of the data packet also complies with the 
IEC 1883 standard. The data_length field contains a value 
representing the number of bytes of data within the data 
field, including the number of bytes within the common 
isochronous packet (CIP) header. The channel field contains 
the channel number on which the isochronous packet is 
transmitted. The tCode field contains the transaction code 
for the packet. For isochronous data packets, the tCode field 
contains either a value of Ah or Ch. The sy field contains a 
synchronization flag used in some applications to synchro- 
nize the data in the current isochronous packet with some 
application specific event. The sourcelD field contains a six 
bit value representing the physical identifying code of the 
node which is transmitting the packet. The values in the 
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other CIP header fields depend on the format of the data 
being transmitted in the packet. The data field, if present, 
contains the content data being transmitted in the packet. 
The data field can contain digital audio, digital video or 

5 some other type of content copy-protected data. The data 
within the data field can also be encrypted or scrambled. 

The authentication mechanism of the present invention is 
alternatively, only enabled when the copy-protected data is 
tagged using a tCode value of "C." Data which is not copy 

10 protected is tagged using a tCode value of "A." If the data 
is transmitted from the source without a tCode value of "C", 
then the authentication mechanism of the present invention 
does not interfere with the reception of the data. 
A block diagram of an exemplary IEEE 1394—1995 serial 

15 bus network including a plurality of devices is illustrated in 
FIG. 3. While the circuit of FIG. 3 shows a network having 
three nodes, it will be apparent to one of ordinary skill in the 
art that the invention will operate with more or fewer nodes 
including any form of application device configured to 

20 operate over an IEEE 1394-1995 serial bus network. A 
video cassette recorder (VCR) 30 includes a physical trans- 
ceiver circuit 32 which is coupled to a physical transceiver 
circuit 42 of a television (TV) 40 through an IEEE 
1394-1995 serial bus cable 36. The physical transceiver 

25 circuit 42 of the TV 40 is also coupled to a physical 
transceiver circuit 52 of a personal computer 50 through an 
IEEE 1394-1995 serial bus cable 46. Together, the devices 
30, 40 and 50 form an IEEE 1394-1995 serial bus network. 
The VCR 30 includes a dedicated register 34 for storing the 

30 physical identifying code of a transmitting device when the 
VCR 30 is receiving copy-protected data. The TV 40 
includes a dedicated register 44 for storing the physical 
identifying code of a transmitting device when the TV 40 is 
receiving copy-protected data. The personal computer 50 

35 includes a dedicated register 54 for storing the physical 
identifying code of a transmitting device when the personal 
computer 50 is receiving copy-protected data. 

Before transmitting data to a device, a transmitting device 
will generally perform some type of authentication operation 

40 to ensure that the receiving device is the correct device to 
which the transmitting device intends to send data. As will 
be apparent to those skilled in the art, there are many well 
known authentication operations used to verify a receiving 
device. Once the transmitting device has completed the 

45 authentication operation and has determined that the receiv- 
ing device is the correct device and authorized to receive the 
copy-protected data, then the transmitting device, as the last 
step of authentication, sends an asynchronous write trans- 
action to a register within the receiving device. The address 

50 and size of this register is preferably known by the trans- 
mitting device. Alternatively, the address and size of this 
register can be determined by the transmitting device as part 
of the authentication process. 
When the receiving device receives the asynchronous 

55 write transaction from the transmitting device, the interface 
hardware within the receiving device latches the value of the 
sourcelD field from the packet header of the transaction into 
the dedicated register. This completes the authentication 
process. Once the authentication process is complete the 

60 transmitting device will then begin to send isochronous data 
packets containing copy protected data to the receiving 
device. Each of the data packets includes the physical 
identifying value of the transmitting device in the sourcelD 
field of the CIP header. When receiving a data packet, the 

65 receiving device will only accept the data packet if the value 
in the sourcelD field of the CIP header matches the value 
stored in the dedicated register. If the value in the sourcelD 



03/26/2004, EAST Version: 1.4.1 



5,94 

5 

field of the CIP header does not match the value stored in the 
dedicated register, the interface hardware of the receiving 
device will prevent the receiving device from accepting the 
data packet. If the value in the sourcelD field of the CIP 
header does match the value stored in the dedicated register, 
the receiving device will receive the data packet and process 
it appropriately. 

The dedicated register within the receiving device can 
only be loaded using a write transaction from an authenti- 
cated transmitting device. User modifiable or user loadable 
software running on the receiving device cannot load the 
sourcelD of the authenticated transmitter of a stream of data. 
Therefore, only an authenticated receiving device verified 
by the transmitting device, will be capable of receiving a 
stream of copy-protected data. 

When a stream of copy-protected data is to be sent from 
the VCR 30 to the TV 40 for display by the TV 40, the VCR 
30 will first perform an authentication process to verify that 
the TV 40 is the correct device and authorized to receive the 
stream of copy-protected data. Once the VCR 30 has verified 
that the TV 40 is authorized to receive the stream of data, the 
VCR 30 then transmits an asynchronous write transaction 
over the IEEE 1394-1995 serial bus network to the dedi- 
cated register 44 within the TV 40. This asynchronous write 
transaction includes the physical identifier of the VCR 30 in 
the sourcelD field of the header. 

When the TV 40 receives the asynchronous write trans- 
action from the VCR 30, the physical transceiver circuit 42 
latches the value of the sourcelD field from the packet 
header of the transaction into the dedicated register 44. The 
VCR 30 will then begin sending the packets of data to the 
TV 40, included within the stream of copy-protected data. 
With each packet of data received, the physical transceiver 
circuit 42 within the TV 40 compares the value in the 
sourcelD field of the received packets to the value stored in 
the dedicated register 44. If the value in the sourcelD field 
of the headers of a received packet matches the value stored 
in the dedicated register 44, the physical transceiver circuit 
42 will accept the packet and forward it to the appropriate 
components within the TV 40. If the value in the sourcelD 
field of the headers of a received packet does not match the 
value stored in the dedicated register 44, the physical 
transceiver circuit 42 will not accept the packet. 

In this manner, the authentication mechanism of the 
present invention uses a hardware implementation to ensure 
that a device only receives copy-protected data that is 
specifically directed to the device. This hardware mecha- 
nism is implemented using a dedicated register within a 
receiving device as a hardware gate. If the value in the 
sourcelD field of the header of a received packet matches the 
value in the register, then the gate is open and the packet is 
received. However, if the value in the sourcelD field of the 
header of a received packet does not match the value in the 
register, then the gate is not open and the packet is not 
received. Because the authentication mechanism is imple- 
mented in hardware and can only be loaded using a write 
transaction from the authenticated transmitting device, user 
modifiable or user loadable software running on the receiv- 
ing node cannot load a value in the dedicated register in 
order to capture a stream of data directed to another device. 
Accordingly, an unauthorized user could not program the PC 
50 to capture the stream of data being transmitted from the 
VCR 30 to the TV 40, because the hardware authentication 
mechanism of the present invention, including the physical 
transceiver 52 and the dedicated register 54, would not 
receive the data packets. The hardware authentication 
mechanism within the PC 50 will only receive the data 
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packets if the PC 50 has been previously authenticated by 
the VCR 30 as an appropriate receiving device. 

It should be apparent to those skilled in the art that while 
a dedicated register is used in the preferred embodiment to 

5 store the value of the transmitting device's physical 
identifier, alternatively any other appropriate storage circuit 
or means can be used to store this value. It should further be 
apparent to those skilled in the art that while the above 
description of the present invention has discussed transmis- 

10 sion of data on a single isochronous channel, the present 
invention can be implemented simultaneously on multiple 
isochronous channels, each having its own authentication 
mechanism. It should also be apparent that the authentica- 
tion mechanism of the present invention can be implemented 
on any type of data stream, including but not limited to both 

15 isochronous and asynchronous data streams. 

The present invention has been described in terms of 
specific embodiments incorporating details to facilitate the 
understanding of principles of construction and operation of 

2Q the invention. Such reference herein to specific embodi- 
ments and details thereof is not intended to limit the scope 
of the claims appended hereto. It will be apparent to those 
skilled in the art that modifications may be made in the 
embodiment chosen for illustration without departing from 
the spirit and scope of the invention. Specifically, it will be 

25 apparent to those skilled in the art that while the preferred 
embodiment of the present invention is used with an IEEE 
1394-1995 serial bus structure, the present invention can 
also be implemented within appropriately configured 

3Q devices within other bus structures. 
I claim: 

1. A method of authenticating a receiving device for 
receiving a stream of data comprising the steps of: 

a. receiving a first identifying value from an originating 
35 device, indicating that the receiving device is autho- 
rized to receive data packets from the originating 
device; 

b. latching the first identifying value into a storage circuit; 

c. receiving packets of data each including a second 
40 identifying value representing the originating device; 

and 

d. accepting packets in a receiving device only when the 
second identifying value matches the first identifying 
value in the storage circuit. 

45 2. The method as claimed in claim 1 further comprising 
the step of comparing the first identifying value to the 
second identifying value. 

3. The method as claimed in claim 2 wherein packets of 
data having the second identifying value which does not 

50 match the first identifying value are rejected. 

4. The method as claimed in claim 3 wherein the storage 
circuit is a dedicated register. 

5. The method as claimed in claim 4 wherein the orgin- 
ating device and the receiving device are coupled together 

55 within an IEEE 1394-1995 serial bus network. 

6. The method as claimed in claim 5 wherein the first and 
second identifying values are included within sourcelD 
fields in different packet headers. 

7. The method as claimed in claim 5 wherein the first 
60 identifying value is transmitted within an asynchronous 

write transaction. 

8. The method as claimed in claim 7 wherein the packets 
of data make up an isochronous stream of data. 

9. An apparatus for authenticating a receiving device 
65 comprising: 

a. a storage circuit for storing a first identifying value 
received from a transmitting device indicating that the 
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receiver is authorized to receive data packets from the 
transmitting device; and 
b. a comparing circuit coupled to the storage circuit for 
comparing a second identifying value from received 
data packets to the first identifying value, wherein only 5 
received data packets having the second identifying 
value matching the first identifying value are provided 
to the receiving device. 

10. The apparatus as claimed in claim 9 wherein the first 
identifying value is received within a write transaction and 10 
latched into the storage circuit. 

11. The apparatus as claimed in claim 10 wherein the 
storage circuit is a dedicated register. 

12. The apparatus as claimed in claim 9 wherein the 
apparatus is coupled as a node within an IEEE 1394-1995 15 
serial bus network. 

13. The apparatus as claimed in claim 12 wherein the 
second identifying value is included within a sourcelD field 
in a header of the received data packets. 

14. An apparatus for receiving communications compris- 20 
ing: 

a. a receiving circuit for receiving communications from 
other devices; 

b. a storage circuit coupled to the receiving circuit for 
storing a first identifying value received from a trans- 



mitting device, indicating that the receiving circuit is 
authorized to receive data packets from the transmitting 
device; and 

c. a comparing circuit coupled to the receiving circuit and 
to the storage circuit for comparing a second identify- 
ing value from received data packets to the first iden- 
tifying value, wherein only received data packets hav- 
ing a second identifying value matching the first 
identifying value are provided to the apparatus and 
received data packets having a second identifying value 
not matching the first identifying value are rejected. 

15. The apparatus as claimed in claim 14 wherein the first 
identifying value is received within a write transaction and 
latched into the storage circuit. 

16. The apparatus as claimed in claim 15 wherein the 
apparatus is coupled as a node within an IEEE 1394-1995 
serial bus network. 

17. The apparatus as claimed in claim 16 wherein the 
second identifying value is included within a sourcelD field 
in a header of the received data packets. 

18. The apparatus as claimed in claim 17 wherein the 
storage circuit is a dedicated register. 
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